In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
After looking at a number of roles and fields that’s involved within User Experience, I looked at how User Experience involves some agile coaching. Something that was mentioned a number of times in this story was value, and how User Experience is … providing value.
When looking at value it’s important to focus on what’s the desired outcome you’re aiming for. Everyone is starting to talk about being outcome based. Organisations are starting to gravitate around OKRs (Objectives & Key Results). And there are plenty of frameworks out there around this.
Studies have shown that committing to a goal can help improve employee performance.
Google re:Work Goal setting
In these frameworks the focus is on outcomes over the output. So it’s not about what you ship, it’s more about the value you create. By defining outcomes as a change in human behaviour that drives business results, you can start to make it possible to really apply the idea of outcomes.
An outcome is a change in human behaviour that drives business results
Focussing on outcomes not outputs
The Project Logic Model, adapted from Kellogg Foundation
The Project Logic Model breaks down the program planning from the resources and the activities you need to do and most important the outputs you create. By having all of those different levels in the model, it helps you specify the thing you are working on more precisely.
A lot of times, the word outcome is used but what is meant is result. That’s fine in casual conversations, but it’s really hard when we’re actually planning work, when we’re trying to write user stories, for example, to just say, “What is the result we want?” It’s a super open question. To have to answer this question for every story is really difficult.
You need to at least have a hunch that if a change is made or a feature added that this will positively change a customer behavior, but you don’t have to know for certain.If we ship a new feature, is it going to create value for the customer? Sometimes we know, and sometimes we don’t know. If we know for certain, then there’s really no reason in even using an outcome focus to begin with.
I might have 6 ideas, I might have 60. But how do I know which one I should be working on?
By using a hypothesis and testing your hypothesis with an experiment or a minimum viable product teams can say: “We think that if we make this feature, it will generate this outcome.”
That experiment might be to make a minimum version of the feature. It might be to talk to people. It might be some kind of research. I don’t think you can ever be 100% certain, but you want to make an effort. This is specifically a technique that, when you mix it with hypotheses and experiments, lets you work your way through that uncertainty.
This can develop meaning for you, your work and your team. If you’re all working towards a common goal, it can also motivate and unite teams.
If you understand your company and it’s business goal then you can also track progress and understand your and your team’s impact. From the business goal you can break it down into what metrics will represent the goal. Which will allow the team to focus on ‘Data-driven design’. Which will help you translate exposed pain points into impacts or blockers within a business context.
Establishing the business context will make it easier to communicate with business stakeholders and discuss priorities.
Frame you product metrics, by using this simple format:
It’s just as important to measure the impact a change has made as it is to change or release new features. Impact can be measured by defining and measuring the success metrics. There are a number of frameworks to help define and measure these:
After making a feature, defining and measuring the right success metrics can validate that the feature is behaving as intended because people are using it in the way that was expected and designed for. That’s a really important discipline. It helps us know whether we can be one and done with the feature or whether we need to go back and iterate. Just shipping features and moving on can lead to leaving a pile of half-finished features behind you and a product that no longer makes sense.
This is key to validating whether you have solve the initial problem. But also to show others the value that you and the team are delivering. This enables the team to feel valued by their peers and organisation, which in itself can bring rewards.
And it’s not just business value where you need to talk a different language. You need to be able to translate any challenge, opportunity or pain point into what it means for the business. Hey, you might even need to translate why you need to do certain things in the design process into business outcomes. This will help translate your value as a designer and what value you are adding to the team or product. This can be done in the following ways:
That’s how you translate your design value into business value.
Change is easier for individuals and teams but much harder for leaders. Leaders have to get out of the business of saying: “I have this solution in my head. Go do it.” Instead, they have to do the work of saying, “Actually, what problem am I asking people to solve?”
When dealing with leaders there is a lot more reputation in play and at risk. So uncertainty can be difficult to handle and deal with. Also leaders aren’t individual players but team players, so they responsibility and have to act on behalf of their teams to make sure they are doing the right thing.
Change starts small. Pick one project or one set of stories where you’ll use the language of agile. Expect it to go okay, not great. Expect to use retrospectives and to continuously improve your process as you try to implement this, because you’ll learn a lot.
As part of looking at how we work to provide value in an agile world. I’ve looked at how User Experience is ... Agile Coaching, as well as how we work to provide value, which are sometimes at odds. So I’m going to explore agile solution design, from architecture to experience.
Originally written as part of the ‘User Experience is …’ series for UX Collective.